A conventional digital computer executes tasks which typically consist of respective sequences of related instructions that are executed to access or modify the contents of a set of registers and memory cells. Each respective sequence will be referred to as a "code thread". In a code thread, the instructions are executed sequentially, one after the other, unless jumps or branches are caused by jump or branch instructions. This usual flow of control in a first "code thread" is often changed by writing in memory the contents of the registers and then executing a second code thread. Since the contents of the registers are saved in memory, execution of the first code thread can be resumed at the point of interruption after the registers are loaded with the contents that were saved in memory. In this fashion, the registers are restored to reestablish the "context" of the first code thread, and the two code threads therefore can be executed independently of each other. This process of saving and restoring the contexts of code threads can be controlled by a master program known as an "operating system" to share a computer among the programs of a number of tasks.
Conventional digital computers include a mechanism to permit an external event asynchronous to instruction execution to change the flow of control. This external event is referred to as an "interrupt". When an interrupt occurs, the processor permits execution of the current instruction to complete, automatically writes in memory the contents of the registers, including the program counter, and then begins instruction execution at a predetermined address referred to as the "interrupt vector". An input/output (I/O) device typically generates such an interrupt signal to cause an I/O service routine to be executed. The service routine typically ends with a "return from interrupt" instruction that causes the registers, including the program counter, to be restored with the contents that were saved in memory, and causes the interrupted flow of control to resume.
The usual flow of control can also be changed by an unusual condition resulting from the execution of an instruction. These unusual conditions are called "exceptions". An exception that occurs after the end of an instruction is called a "trap". An "arithmetic trap", for example, occurs at the end of a divide instruction when a divide by zero is attempted. The operating system typically has an error handler routine that is executed in response to arithmetic traps. A trap can also be explicitly called for by a "software interrupt" instruction that causes the contents of the registers, including the program counter, to be stored in memory, and then begins instruction execution at a specified address.
Another kind of exception, known as a "fault", arises before the completion of an instruction. In response to the fault, the register values are saved in memory, and a "fault handler" routine of the operating system is executed. If the "fault handler" can correct the condition, the registers are restored and execution of the instruction is restarted. If the condition cannot be cleared, the exception is called an "abort".
Many computers include registers that indicate condition codes or report pending interrupts. A computer system, for example, may include a number of I/O units, all of which are serviced by the same interrupt routine. The interrupt routine usually begins by polling the registers that specify which I/O unit needs to be serviced. In more complex computer systems, the hardware automatically prioritizes similar interrupts and causes a respective interrupt routine to be executed for each interrupt. These more complex systems usually include registers which permit respective priorities to be assigned to various interrupts and also permit a priority to be assigned to the program or code thread currently being executed by the processor. An interrupt will not be recognized or serviced by the processor until the priority of the code thread is lower than the priority of the interrupt.
By providing special hardware that automatically recognizes exceptions and interrupts, the software does not have to constantly check for special conditions, completions of the device operations, or erroneous arithmetic results. Instead, the hardware automatically reports the occurrence and prioritizes its servicing. Through the use of exception and interrupt vectors, the action to take for each condition can be specified in advance.
In a timesharing system, it is desirable to suspend the execution of a first code thread for a first user to execute a second code thread for a second user when the first code thread is waiting for data requested from an I/O device. Usually this is done by lowering the priority of the first code thread after an I/O request. But it is also necessary to provide a mechanism for passing the data from the I/O device back to the first code thread. One way of doing this is by defining an "Asynchronous System Trap" (AST) for the first code thread. An AST is a call of a routine within the context of a code thread, that is asynchronous to the execution of the code thread. Before issuing an I/O request, the first code thread, for example, specifies a routine to be called when the requested I/O is completed. This routine is called an Asynchronous System Trap routine, because it is called when an asynchronous event occurs. If the first code thread is executing when the event occurs, it will be interrupted and the AST routine will be called. When the AST routine returns, program execution continues from the interrupted point. In any event, the AST routine is within the context of the first code thread, so that the AST routine can pass data to the first code thread simply by executing an instruction that modifies the contents of a register.
When the I/O device is ready to respond to the I/O request, it issues an interrupt signal to the processor. Therefore, to define the AST, a linkage must be set up between the interrupt routine of the I/O device and the context of the first code thread associated with the AST. In other words, before requesting the I/O operation, the first code thread must enable the interrupt routine for the I/O device to call the AST routine, and before the AST routine is executed, the registers must be loaded with the context of the first code thread associated with the AST. The linkage between the interrupt routine of the I/O device and the AST routine, for example, is defined by an entry in a respective queue of AST routine addresses associated with the I/O device to permit a number of I/O requests from different code threads to be pending at any given time.
In a timesharing system, the AST could be called when the I/O interrupt occurs to interrupt the execution of any code thread currently being executed. But if a code thread other than the one associated with the interrupt it being executed, it is preferable to delay the calling of the AST routine until the operating system permits the first code thread to be executed. At that later time the operating system enables the servicing of the interrupt routine for the I/O device, the restoring of the registers with the context of the first code thread, and the calling of the AST routine.
Asynchronous exceptions also arise when specialized functional units are implemented as coprocessors. The coprocessor can operate either synchronously or asynchronously with respect to the main processor which issues instructions to the coprocessor. For asynchronous execution, the coprocessor can execute an issued instruction simultaneously while the main processor executes further instructions. But during synchronous execution, after the main processor issues an instruction to the coprocessor, the main processor does not process any further instructions until the issued instruction is guaranteed to complete, without causing an exception.
An example of asynchronous execution is the Digital Equipment Corporation's PDP-11/45 and PDP-11/55 FP11-C Floating Point Processor which is described in the PDP11 04/34/45/55 Processor Handbook, Digital Equipment Corporation, 1976. Overlapped operation of the FP11-C and a central processor is implemented as follows. When a FP11-C instruction is fetched from memory the FP11-C will execute that instruction in parallel with the central processor continuing its instruction sequence. The central processor is delayed a very short period of time during the FP11-C instruction fetch operation, and then is free to proceed independently of the FP11-C. The interaction between the two processors is automatic, and a program can take full advantage of the parallel operation of the two processors by intermixing floating point processor and central processor instructions.
When an FP11-C instruction is encountered in a program, the central processor first initiates floating point handshaking and calculates the address of the operand. It then checks the status of the floating point processor. If the FP11-C is "busy", the central processor will wait until the FP11-C is "done" before continuing execution of the program.
One interrupt vector is assigned to take care of all of the FP11-C floating point exceptions. Seven errors are possible and they are coded in a four bit "floating exception code" register (FEC) as follows: floating OP-code error (FEC=2); floating divide by zero (FEC=4); floating (or double) to integer conversion error (FEC=6); floating overflow (FEC=8); floating underflow (FEC=10); floating undefined variable (FEC=12); and maintenance trap (FEC=14). The address of the instruction producing the exception is stored in a "floating exception address" (FEA) register. The operating system handles the floating point exception by extracting the FEC and FEA registers, and delivering a "floating point processor exception" AST to the task.
An example of synchronous execution is one operating mode of the MIPS R2000 data processing system described in a reference manual by Gerry Kane entitled MIPS R2000 RISC Architecture, MIPS Computer Systems, Inc., 1987. In this case the data processing system includes a main processor and a floating-point coprocessor. The floating-point coprocessor has a Control/Status register that contains control data and status data. (See page 6-5.) The control data controls the rounding of arithmetic results and enabling of exceptions. The status data indicates exceptions that occurred in the most recently executed instruction, and all exceptions that have occurred since the Control/Status register was cleared.
On page 8-10 of the MIPS R2000 RISC Architecture reference manual, it is said that thirty-two coprocessor load or store instructions will save the floating-point coprocessor's floating-point state in memory. The contents of the Control/Status register can be saved using the "move to/from coprocessor control register" instructions (CTC1/CFC1). Normally, the Control/Status register contents are saved first and restored last. The "exceptions" field of the Control/Status register holds the results of only one instruction: the floating-point coprocessor examines the source operands before an operation is initiated to determine if the instruction can possibly cause an exception. If an exception is possible, the floating-point coprocessor executes the instruction in "stall" mode to ensure that no more than one instruction at a time is executed that might cause an exception. All bits in the "exceptions" field can be cleared by writing a zero to this field. This permits restarting of normal processing after the Control/Status register state is restored.
Another example of synchronous execution is the operation of the IBM System/370 vector facility. The vector instructions are executed sequentially, and any exceptions encountered during execution of the instructions are recognized sequentially. Only one exception at a time is allowed to cause an interruption. At the point of interruption, all preceding vector element operations have been completed successfully, and any subsequent operations that have already been performed are discarded as though they have not yet occurred.
Synchronous operation avoids the problem of delayed exceptions, but at the expense of decreasing the overall system performance. With asynchronous operation, the main processor does not need to delay or suspend its current execution of instructions unless the instruction is to synchronize with the coprocessor.
In short, asynchronous execution of the coprocessor operations vis-a-vis the main processor can greatly improve the overall performance of the system. Asynchronous execution of the coprocessor, however, causes reporting of coprocessor exceptions to the user program to be delayed by an imprecise amount of time. Delayed exceptions present a problem to the execution of multiple code threads within a process. An exception condition generated by one code thread may be reported during an unrelated code thread, making fault isolation difficult.